home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4252 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: What will happen close to 640K limit ?
  5. Date: 2 Feb 1996 13:27:39 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4etvkbINN8dg@keats.ugrad.cs.ubc.ca>
  8. References: <Pine.SOL.3.91.960128110843.26154C-100000@hamlet.uncg.edu> <4ein9b$330@news.bellglobal.com>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4ein9b$330@news.bellglobal.com>,
  12. Steve Tupy <stupy@freenet.durham.org> wrote:
  13. >: I wrote a DOS program, with size about 512K, which is the size when I use
  14. >: dir to check it.
  15. >:  
  16. >    This may not be totally reliable...
  17. >
  18. >: I also use dos command mem to check dos avaible memory, which gave me max
  19. >: execute file size 560k, because there are some device driver I load in 
  20. >: the config.sys, I knew 512k is not real program size, there are some 
  21. >: stack variable and memory allocated on heap.
  22. >
  23. >: Now my program is not stable, it can work for fine for couple days, then 
  24. >: it lock up. It may just lock up keyboard or screen, it may also reboot 
  25. >: PC, I wonder if because it close to 640 K limit ? How can I check the  real
  26. >: program size include stack size and heap ?
  27. >    
  28. >    Because DOS is not reentrant, if you intend to run it for any length
  29. >of time WITH memory allocation/deallocation, you almost MUST implement some
  30. >sort of garbage collection scheme to "defrag" your memory segments. This is
  31. >why you see all these BBS packages dumping out of memory and loading up
  32. >again from the command line, it flushes the memory back to the original
  33. >point, in a manner of speaking. You can either avoid memory allocation,
  34. >implement a garbage collector or reload your program from time to time,
  35. >these are about the only ways to deal with this problem that I know of...
  36.  
  37. This is all true, but it has nothing to do with reentrancy (nor comp.lang.c)
  38. and everything to do with lack of virtual memory management to eliminate
  39. external fragmentation and to provide address spaces that are larger than what
  40. is physically available.
  41.  
  42. These problems were effectively solved long before DOS, so the latter is not
  43. worth discussing, really.
  44.  
  45. Regarding fragmentation, there is an article in an old issue of the Journal of
  46. the ACM (something like vol. 18).  It contains a proof that if a requestor
  47. allocates and deallocates blocks that have power of two sizes from 1 to 2^b,
  48. and at no time allocates more than N bytes, the worst case scenario will
  49. require something like N * (1 + b) bytes; that is, the allocator plays the
  50. optimal strategy to maximize the memory footprint.
  51.  
  52. This means that if you are grabbing blocks between 1 byte and 4K in size up to
  53. a limit of 1MB total, you could end up claiming as much as 13MB of storage and
  54. not be able to fill a 4K allocation request without requiring additional memory
  55. from the OS. Rather pessimistic!
  56.  
  57. Also note that if your VM scheme is based on 4K pages, in this case you can't
  58. even return a single page to the OS, because if you could, that would mean you
  59. have a "hole" in your heap that is at least 4K large, and you _could_ satisfy 
  60. the largest possible allocation request of 4K without increasing the heap.
  61.  
  62. Mind you, J. M. Robson (the article's author) only proved the result for block
  63. sizes that are dyadic powers.
  64. -- 
  65.  
  66.